Extensible Markup Language (XML) is a powerful platform independent tool for the storage and display of data. As information stored in XML is arranged in a nested or hierarchical format which reflects the underlying structure of the information, this makes it particularly suitable for the storage of data such as personnel information and the like. Additionally, XML is particularly suited to the input and display of information by tools used commonly for the World Wide Web (WWW). Accordingly, there are a number of enterprise resource planning (ERP) and database systems employed to manage the process of recruitment and employee management that employ XML as one data format for storing information related to a candidate which may be easily searched or otherwise post processed.
Referring now to FIG. 1, there is shown an ERP system 100 of the type that employers or specialist recruiters acting on behalf of an employer utilize to manage the process of recruitment of new candidates and also succession planning within an organization. In ERP system 100, a prospective candidate will be able to enter their relevant details into a central structured database 110 using a candidate interface 130. The candidate interface 130 interacts with a database application layer 120 that manages the retrieval of the relevant details in the correct data tables as requested.
A recruiter wishing to obtain information about suitable candidates is able to form a customized information request by employing recruiter customization module 140 that indicates to XML generator 150 to generate candidate search profiles 155 in XML format having this customized information. This information may in one example include only details such as work experience and education where in this case other candidate information is not relevant for a given recruitment task.
Alternatively, the candidate search profiles 155 may be generated by XML generator 150 to contain all relevant data provided by a candidate and in this case the recruiter customization module 140 will customize the capability of the recruiter applications 170 to have access to either all or part of the candidate information provided by the candidate. For example, where the recruiter application 170 involves a searching tool, the recruiter would in a similar scenario to that outlined above, only be able to perform searches of candidate search profiles 155 based on candidate education or work experience.
Candidate search profiles 155 are then indexed by indexer 160 into search engine index 165. This indexing process provides the capability to rapidly rank and search the candidate information. Candidate search profiles 155 are also stored in XML format in database 110. Recruiter applications 170 are then able to post process the information contained in the candidate search profiles 155 by accessing the search engine index 165. One example of a recruiting application 170 would be a searching tool that is able to send search queries in XML format to rank candidate search profiles 155 that have been indexed in search engine index 165 according to predetermined criteria.
Candidates control the accessibility of their information by being able to change their candidate status from a “RELEASED” state to a “LOCKED” state via the candidate interface 130. When a candidate changes their candidate status to the “LOCKED” state, this signals 130A the database application layer 120 to delete the corresponding candidate search profile 156 from the database 110, thereby protecting the privacy of the candidate.
Whilst this approach functions to protect the privacy of the candidate, it also results in the candidate search profile 156 having to be deleted each time the candidate status is changed to the “LOCKED” state and then subsequently regenerated in its entirety if the candidate should choose once again to change their candidate status to “RELEASED”. Accordingly, the corresponding data records stored in database 110 and the candidate search profiles 155 generated from these data records are no longer synchronized with resynchronization only occurring when the candidate changes their candidate status to “RELEASED” again.
This can result in potential inconsistencies between other applications which directly access and post process the candidate data records in database 110 that correspond to the generated candidate search profiles 155 and the recruiter applications 170 which directly access the candidate search profiles 155 by virtue of search engine index 165. Additionally, any useful information that could be derived from the locked candidate search profile 156 that would not necessarily violate the privacy of the candidate concerned is lost as this candidate search profile 156 has been deleted.
Another significant disadvantage of this approach is that at the recruiter customizing stage 140, the recruiter is limited to generating or alternatively post processing information in the candidate search profiles 155 that corresponds directly to data fields in the database 110.